【翻訳】ストーリーポイントを使うのをやめよう - PoohSunny's blog
アジャイルに対する警鐘。2012年・・・・だと・・・ とはいえ見積もりはせざるを得ない（いつ完成するのか分からなくなる）のでどうしたもんか・・・
2004年のある日、ジムはより早く進められるようチームを励ましました。
彼はスクラムに精通していないにもかかわらず、「スプリント」という用語を利用します。
このチームは、イテレーションごとに平均52ポイントのベロシティがありました。
彼らのベロシティは数ポイント上下することもありましたが、基本的には安定していました。
しかしジムがチームに「スプリント」という言葉を使った数週間後、チームのベロシティは80台に跳ね上がりました！
私は誰かに何が起きたのかを尋ねました。
彼女は笑いながら私を見て、「ここでは最近、あなたがくしゃみをするとストーリーポイントが得られるの」と言いました。
評価され、私と他のIndustrial Logicの二人のコーチにトレーニングとコーチを受けた成熟したアジャイルチームが、彼らが早く進んでいるように見せるために突然ストーリーポイントでの見積もりを膨らませてしまうことがあることにとても驚き、頭を振りました。
私のストーリーポイントとベロシティへの自信は、この経験のあと侵食され始めました。
ストーリーポイントは、基準にしたタスクに対する相対見積もりなので、1日で終わるタスクを20ポイントとかで計算すれば、そりゃ数字は大きくなるわな。と言う現象。
マネージャー（ジムさん）は数字の大きさが進捗の大きさであると誤認してしまっている。
長年にわたって、複数の会社のマネージャーがこう尋ねるのを聞いてきました。「Xチームは24ポイントをスプリントでDoneにできるのに、Yチームはたったの12ポイントしかDoneにできないのはなぜでしょうか？ チームのサイズはほぼ同様なのに、この差はなぜできるのでしょうか？」
似たような話。数字って怖いね・・・
とても長いあいだ、私は一定のベロシティを保持することが大事だと考えていました。なぜなら、計画時にいつプロダクトやシステムが完成するのかを予測するのを助けると考えていたためです。
しかし、バーンダウンチャートを良く見せたり、見積もりを作成したり超えたりするために、品質を犠牲にしたりただ技術的負債を積み上げるチームをいくつも見てきました。
期日を計画することで、品質が下がる例。
多くのストーリーポイントの利用の正当化根拠は、人間は実際の時間での見積もりが得意ではない、というものです。
我々は仕事が終わるまでどれくらいかかるかを見積もっているのではなく、仕事の大きさを見積もっているので、ストーリーポイントは我々をよりよい見積もりをもたらしてくれると支持者は言います。
実際に、どんな尺度が利用されているかに関わらず、人間は一般に見積もりは得意ではありません。
後ほどお見せするように、チームがよい見積もりを得るのは、頻繁に見積もり直した時です。
ストーリーポイントは問題をさらに混乱させるだけです。
人類は時間見積もりが得意ではない。のではなく、見積もりって行為自体が苦手なんだよ。と言う話
見積もりを行う理由は完成日の予測であるにもかかわらず、時間を使わないので、ストーリーポイントから時間への変換も手間がかかる。とも。
---
ドンはエクストリームプログラミングのメーリングリストからのこのメールで下記のように言及しました：
我々は完了した項目を数えています。毎週最も重要なアイテムを選んで、先週こなした数の分だけ印をつけます。見積もりに力をかけるか否かにかかわらず、先週とほぼ同じ数のアイテムができると判明しました。私たちは1週間イテレーションなので、イテレーションの計画ミーティングでブレイクダウンをします。
おそらく効果は、物事を正しいサイズに分割する方法を学んだことです。私はまだ分かっていませんが、我々は大体8個を毎週完了させられるというのがポイントです。見積もりは必要ありません。
タスク（アイテム）の粒度がそろってる事による、予測可能性。粒度を揃えるセンスが必要・・・
固定の長さのタイムボックスで作業することを無くし、私たちはただ行うべき重要な仕事を少し選び、完了させ、出荷する、というのを繰り返しました。
一般に、仕事を完了するまでに1日かかるか4日かかるかなどは気にしませんでした。
私たちは、固定されたタイムボックスで仕事をすることや、完成したストーリーポイントの数を追跡したりすることではなく、出荷することにフォーカスしていました。
新しいプロセスを利用して、平均で週に1〜2回出荷をしました。
我々のアジリティは、プロセスから一部神聖なものを除くことで増加しました。
アジャイルマニフェストの第一原則に則ってデリバーすることで、私たちはより良いものになりました。
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
締め切りがある場合は、すべての仕事を完了するか、後のリリースまで安全に延期できる仕事を見つけるようにしていました。
我々のプランニングのセッションはとても短く、一貫したベロシティを維持したかではなく、貴重なソフトウェアを出荷したかどうかで自分たちを評価しました。
見積もりを止めた。
進捗を評価するのではなく、価値を生むリリースが出来たかどうかを評価する。
この最初のプロジェクトが完了して数ヶ月後、その会社は全社的にアジャイルを展開するために我々が支援できるかを尋ねました。
そこで我々は、プロセスの移行をを既に終えていた最初のチームへのインタビューを含む移行計画を策定しました。
そのチームのオープンワークスペースに入ったとき、バーンダウンチャート、リリース計画、イテレーションの計画、そして日々のチームのベロシティをトラッキングしているチャートで覆われた壁が見えました。
私はこの会社の最高のプロダクトマネージャーであると評判の女性と座りました。
数分の会話の後、私は壁のポスターのいくつかを指さし、計画と見積もりでどのようなことが起こっているのかを尋ねました。
少しの間を置いた後、彼女は笑いながら私を見ました。
それから彼女はすべての物事は順調で、ストーリーポイントを利用したベロシティを測定し、イテレーションとリリースで正しい業務量をベロシティを用いてスケジューリングしていると言いました。
彼女の表現が、何かが間違っていることを示唆していました。
「確かですか？」私は尋ねました。
彼女は数秒間止まった後、「本当の答えを知りたいですか？」と言いました。
私がうなづくと、彼女は、「ベロシティの数が入ったポスターを見ましたか？ 我々はあなたがここへ来ることを知っていて、あなたに我々の良いことについて上司に言って欲しかったので、我々はこれを作りました。」と告げました。
「本当ですか？！？」私は驚いて尋ねました。「それで、実際は何をしているのですか？」
彼女はチームが2週間のイテレーションや、2ヶ月のリリースに正しい業務量を選ぶために、単に直感を利用していると説明しました。
もし彼女たちが計画を修正する必要がある場合、ただ修正するだけです。それは常にステークホルダーに知らされます。
直感による見積もりと計画づくりというアプローチはうまく言っており、ストーリーポイントやベロシティの計算は不要だと彼女は言いました。
私は彼女のアプローチのシンプルさを褒め称え、彼女がやっていたことは完全にアジャイルで、ストーリーポイントの利用はアジャイルになることに不可欠ではないと彼女に保証しました。
そして一年前に、Industrial Logicがどのようにプロダクト開発でのストーリーポイントの利用をやめたのかを説明しました。
TODO：周期的なリリース計画
ねむい
https://gyazo.com/f7d0f06c310a5338c9a3f626171d8047